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1. INTRODUCTION 

The goal of the Haskell committee was to design a standard lazy functional lan- 
guage, applying existing, well-understood methods. To the committee's surprise, it 
emerged that there was no standard way to provide overloaded operations such as 
equality (==), arithmetic (+), and conversion to a string (show). 

Languages such as Miranda 1 [Turner 1985] and Standard ML [Milner and Toftc 
1991; Milner et al. 1990] offer differing solutions to these problems. The solutions 
differ not only between languages but within a language. Miranda uses one tech- 
nique for equality (it is defined on all types — including abstract types on which it 
should be undefined!), another for arithmetic (there is only one numeric type), and 
a third for string conversion. Standard ML uses the same technique for arithmetic 
and string conversion (overloading must be resolved at the point of appearance), 
but a different one for equality (type variables that range only over equality types) . 

The Haskell committee adopted a completely new technique, based on a proposal 
by Wadler, which extends the familiar Hindley-Milner system [Milner 1978] with 
type classes. Type classes provide a uniform solution to overloading, including 



Miranda is a trademark of Research Software Limited. 



This work is supported by the UK EPSRC AQUA, Parade, and Save Space grants, and by an 
SOED fellowship from the Royal Society of Edinburgh. 

Authors' address: Computing Science Department, Glasgow University, 17 Lilybank Gardens, 
Glasgow, Scotland. 

Permission to make digital/hard copy of all or part of this material without fee is granted 
provided that the copies are not made or distributed for profit or commercial advantage, the 
ACM copyright/server notice, the title of the publication, and its date appear, and notice is given 
that copying is by permission of the Association for Computing Machinery, Inc. (ACM). To copy 
otherwise, to republish, to post on servers, or to redistribute to lists requires prior specific 
permission and/or a fee. 

© 1996 ACM 0164-0925/96/0300-0109 $03.50 



ACM Transactions on Programming Languages, Vol. 18, No. 2, March 1996, Pages 109-138. 



110 • Cordelia V. Hall et al. 



providing operations for equality, arithmetic, and string conversion. They generalize 
the idea of equality types from Standard ML and subsume the approach to string 
conversion used in Miranda. This system was originally described by Wadler and 
Blott [1989], and a similar proposal was made independently by Kaes [1988]. 

The type system of Haskell is certainly its most innovative feature and has pro- 
voked much discussion. There has been closely related work by Rouaix [1990] and 
Cormack and Wright [1990]; Nipkow and Snelting [1991] and Nipkow and Pre- 
hofer [1993] also describe type inference algorithms for type classes based on sorts; 
and work directly inspired by Haskell type classes includes the closely related Gofer 
type system with its multiparameter classes [Jones 1992a; 1992b; 1994], an exten- 
sion of ML with type classes [Volpano and Smith 1991], constructor classes [Jones 
1995], first-class abstract data types [Laufer 1992; 1993; Laufer and Odersky 1994; 
Odersky and Laufer 1991], and parametric type classes [Chen 1994; 1995; Chen et 
al. 1992]. 

This article presents a source language (lambda calculus with implicit typing 
and with overloading) and a target language (polymorphic lambda calculus with 
explicit typing and without overloading) . The semantics of the former is provided by 
translation into the latter, which has a well-known semantics [Huct 1990]. Normally, 
one expects a theorem stating that the translation is sound, in that the translation 
preserves the meaning of programs. That is not possible here, as the translation 
defines the meaning of programs. It is a shortcoming of the system presented here 
in that there is no direct way of assigning meaning to a program, and it must 
be done indirectly via translation; but there appears to be no alternative. (Note, 
however, that Kaes [1988] does give a direct semantics for a slightly simpler form 
of overloading.) 

The original type inference rules given by Wadler and Blott [1989] were deliber- 
ately rather sparse and were not intended to reflect the Haskell language precisely 
As a result, there has been some confusion as to precisely how type classes in Haskell 
are defined. 

1.1 Contributions of this Article 

In comparison with previous work, this article makes several new contributions. 

(1) With the few exceptions noted in Section 1.2, this article spells out the precise 
definition of type classes in Haskell. These rules arose from a practical impetus: 
our attempts to build a compiler for Haskell. The rules were written to provide 
a precise specification of what type classes were, but we found that they also 
provided a blueprint for how to implement them. 

(2) This article presents a simplified subset of the rules we derived. The full static 
semantics of Haskell [Peyton Jones and Wadler 1991] contains over 30 judgment 
forms and over 100 rules. The reader will be pleased to know that this article 
simplifies the rules considerably, while maintaining their essence in so far as type 
classes are concerned. The full rules are more complex because they deal with 
many additional syntactic features such as type declarations, pattern matching, 
and list comprehensions. 

(3) This article shows how the static analysis phase of our Haskell compiler was 
derived by adopting directly the rules in the static semantics. This was gener- 
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ally a very straightforward task. In our earlier prototype compiler, and in the 
prototype compilers constructed at Yale and Chalmers, subtleties with types 
caused major problems. Writing down the rules has enabled us to discover 
bugs in the various prototypes and to ensure that similar errors cannot arise in 
our new compiler. We have been inspired in our work by the formal semantics 
of Standard ML prepared by Milner et al. [1990; 1991]. We have deliberately 
adopted many of the same techniques they use for mastering complexity. 
(4) This approach unites theory and practice. The industrial-grade rules given 
here provide a useful complement to the more theoretical approaches of Wadlcr 
and Blott [1989], Blott [1991], Nipkow and Snelting [1991], Nipkow and Prc- 
hofer [1993], and Jones [1992a; 1992b; 1993]. A number of simplifying assump- 
tions made in those papers are not made here. Unlike Wadler and Blott [1989], 
it is not assumed that each class has exactly one operation. Unlike Nipkow and 
Snelting [1991], it is not assumed that the intersection of every pair of classes 
must be separately declared. Unlike Jones [1992a; 1992b], we deal directly with 
instance and class declarations. Each of those papers emphasizes one aspect 
or another of the theory, while this article stresses what we learned from prac- 
tice. At the same time, these rules provide a clean, "high-level" specification 
for the implementation of a typechecker, unlike more implementation-oriented 
papers [Augustsson 1993; Hammond and Blott 1989]. 

A further contribution of this work is the use of explicit polymorphism in the 
target language, as described in Sections 1.3 and 5.2. 

1.2 Outstanding Issues 

Since this article docs not attempt to be a complete semantics for type classes in 
Haskell, there are a number of issues which are not addressed here. These issues 
are addressed by the full static semantics [Peyton Jones and Wadler 1991]. The 
most important of these arc: 

(1) The rules do not allow polymorphic class methods: the only type variable 
which can appear in the type of a method is the one constrained by the class 
declaration. It would be straightforward to extend the rules to cover this case. 

(2) There is no treatment of the Haskell monomorphism restriction, which was 
introduced in Haskell 1.1 for efficiency reasons. Essentially, the restriction 
limits the use of the GEN rule for value definitions with overloaded types, so 
that overloaded type variables are generalized only for function definitions or if 
an explicit type signature is provided. This improves sharing in the translation: 
since an overloaded value could be used at multiple types it would normally 
need to be recomputed once for each occurrence in the enclosing definition; the 
monomorphism restriction ensures that (1) the value is used only at one type 
and (2) that the result may therefore be reused. Papers by Hammond and 
Blott [1991] and Augustsson [1993] consider this in more detail. 

(3) This article does not consider the use of default types to resolve certain type 
ambiguities. While the use of default types has been found to be invaluable in 
practice, they can technically lead to an incoherent semantics, as demonstrated 
by Blott [1991]. A good treatment of ambiguity in type classes can be found 
in Nipkow and Prchofer [1993]. 
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1.3 A Target Language with Explicit Polymorphism 

As in Wadler and Blott [1989], Nipkow and Snelting [1991], and Jones [1992a; 
1992b], the rules given here specify a translation from a source language with type 
classes to a target language without them. The translation implements type classes 
by introducing extra parameters to overloaded functions, which are instantiated at 
the calling point with dictionaries that define the overloaded operations. 

The target language used here differs in that all polymorphism has been made 
explicit. In Wadler and Blott [1989], Nipkow and Snelting [1991], and Jones [1992a; 
1992b], the target language resembles the implicitly typed polymorphic lambda 
calculus of Hindley [1969] and Milncr [1978]. Here, the target language resembles 
the explicitly typed second-order polymorphic lambda calculus of Girard [1972] and 
Reynolds [1974]. It has constructs for type abstraction and application, and each 
bound variable is labeled with its type. 

The reason for using this as our target language is that it makes it easy to extract 
a type from any subterm. This greatly cases later stages of compilation, where 
certain optimizations depend on knowing a subterm's type. An alternative might 
be to annotate each subterm with its type, but our method has three advantages. 

(1) It uses less space. Types are stored in type applications and with each bound 
variable, rather than at every subterm. 

(2) It eases subsequent transformation. A standard and productive technique for 
compiling functional languages is to apply various transformations at interme- 
diate phases [Peyton Jones 1987]. With annotations, each transformation must 
carefully preserve annotations on all subterms and add new annotations where 
required. With polymorphic lambda calculus, the usual transformation rules — 
e.g., /3-reduction for type abstractions — preserve type information in a simple 
and efficient way. 

(3) It provides greater generality. Our back end can deal not only with languages 
based on Hindlcy-Milncr types (such as Haskell) but also languages based on 
the more general Girard- Reynolds types (such as Ponder). 

The use of explicit polymorphism in our target language is one of the most innova- 
tive aspects of this work. Further, this technique is completely independent of type 
classes — it applies just as well to any language based on Hindley- Milner types. 

1.4 Structure of the Article 

This article does not assume prior knowledge of type classes. However, the intro- 
duction given here is necessarily cursory; for further motivating examples, see the 
original paper by Wadler and Blott [1989]. For a comparison of the Hindlcy-Milncr 
and Girard- Reynolds systems, see the excellent summary by Reynolds [1985]. For 
a practicum on Hindley-Milner type inference, see the tutorial by Cardelli [1987]. 

The remainder of this article is organized as follows. Section 2 introduces type 
classes and our translation method. Section 3 describes the various notations used 
in presenting the inference rules. The syntax of types, the source language, and the 
target language is given, and the various forms of environment used are discussed. 
Section 4 presents the inference rules. Rules are given for types, expressions, dictio- 
naries, class declarations, instance declarations, and programs. Finally, Section 6 
describes how these rules can be used directly in a monad-based implementation. 



ACM Transactions on Programming Languages, Vol. 18, No. 2, March 1996. 



Type Classes in Haskell • 113 



2. TYPE CLASSES 

This section introduces type classes and defines the required terminology. Some 
simple examples based on equality and comparison operations are introduced. Some 
overloaded function definitions are given, and we show how they translate. The 
examples used here will appear as running examples through the rest of the article. 

2.1 Classes and Instances 

A class declaration provides the names and type signatures of the class operations: 

class Eq a where (==) :: a -> a -> Bool 

This declares that type a belongs to the class Eq if there is an operation (==) of 
type a -> a -> Bool. That is, a belongs to Eq if equality is defined for it. 

An instance declaration provides a method that implements each class operation 
at a given type: 

instance Eq Int where (==) = primEqlnt 
instance Eq Char where (==) = primEqChar 

This declares that type Int belongs to class Eq and that the implementation of 
equality on integers is given by primEqlnt, which must have type Int -> Int 
-> Bool. The same is true for characters. 

Under this system both 2+2 == 4 and 'a' == 'b' are well typed. As usual, 
x == y abbreviates (==) x y. In our examples, we assume all numerals have type 
Int. 

Functions that use equality may themselves be overloaded: 

member = \ x ys -> not (null ys) &:& (x == head ys I I member x (tail ys)) 

This uses Haskell lambda expressions: \ x ys -> e stands for Ax. Ays. e. In prac- 
tice we would use pattern matching rather than null, head, and tail, but here we 
avoid pattern matching, since we give typing rules for expressions only. Extending 
to pattern matching is easy, but adds unnecessary complication. 

The type system infers the most general possible signature for member: 

member :: (Eq a) => a -> [a] -> Bool 

The phrase (Eq a) is called a context of the type — it limits the types that a can 
range over to those belonging to class Eq. As usual, [a] denotes the type of lists 
with elements of type a. The two expressions (member 1 [2 , 3] ) or (member ' a ' 
['c' , 'a' , 't'] ) arc therefore well typed, but (member sin [cos, tan]) is not, 
since there is no instance of equality over functions. A similar effect is achieved 
in Standard ML by using equality type variables; type classes can be viewed as 
generalizing this behavior. 

Instance declarations may themselves contain overloaded operations, if they are 
provided with a suitable context: 

instance (Eq a) => Eq [a] where 

(==) = \ xs ys -> (null xs && null ys) I I 

(not (null xs) && not (null ys) && 
head xs == head ys && tail xs == tail ys) 



ACM Transactions on Programming Languages, Vol. 18, No. 2, March 1996. 



114 • Cordelia V. Hall et al. 



This declares that for every type a belonging to class Eq, the type [a] also belongs 
to class Eq and vice versa, and gives an appropriate definition for equality over 
lists. Note that head xs == head ys uses equality at type a, while tail xs == 
tail ys recursively uses equality at type [a] . The expression ['c'.'a'.'t'] == 
['d','o','g'] is therefore well typed. 

Every entry in a context pairs a class name with a type variable. Pairing a class 
name with a more specific type is not allowed. For example, consider the definition: 

palindrome xs = (xs == reverse xs) 

The inferred signature is: 

palindrome :: (Eq a) => [a] -> Bool 

Note that the context is (Eq a) , not (Eq [a] ) . The simpler context can be inferred 
from the context for the instance declaration, since whenever the type [a] belongs 
to class Eq, the type a must also belong to class Eq. 

2.2 Superclasses 

A class declaration may include a context that specifies one or more superclasses: 

class (Eq a) => Ord a where 

(<) :: a -> a -> Bool 
(<=) :: a -> a -> Bool 

This declares that type a belongs to the class Drd if there are operations (<) and 
(<=) of the appropriate type and if a belongs to class Eq. Thus, if (<) is defined 
on some type, then (==) must be defined on that type as well. We say that Eq is 
a superclass of Drd. 

The superclass hierarchy must form a directed acyclic graph. An instance dec- 
laration is valid for a class only if there are also instance declarations for all its 
superclasses. For example 

instance Ord Int where 

(<) = primLtlnt 
(<=) = primLelnt 

is valid, since Eq Int is already a declared instance. 

Superclasses allow simpler signatures to be inferred. Consider the following def- 
inition, which uses both (==) and (<): 

search = \ x ys -> not (null ys) && ( x == head ys I I 

( x < head ys && search x (tail ys)) 

The inferred signature is: 

search :: (Ord a) => a -> [a] -> Bool 
Without superclasses, the context would have been (Eq a, Ord a). 

2.3 Translation 

The inference rules specify a translation of source programs into target programs 
where the overloading is made explicit. 

Each instance declaration generates an appropriate corresponding dictionary dec- 
laration. The dictionary for a class contains dictionaries for all the superclasses and 
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methods for all the operators. Corresponding to the Eq Int and Ord Int instances, 
we have the dictionaries: 

dictEqlnt = ( (}, primEqlnt) 

dictOrdlnt = ( (dictEqlnt), primLtlnt, primLelnt) 

Here (ei, . . . , e n ) builds a dictionary. The dictionary for Ord contains a dictionary 
for its superclass Eq and methods for (<) and (<=). 

For each operation in a class, there is a selector to extract the appropriate method 
from the corresponding dictionary. For each superclass, there is also a selector to 
extract the superclass dictionary from the subclass dictionary. Corresponding to 
the Eq and Ord classes, we have the selectors: 

(==) = \<<), == > "> == 

getEqFromOrd = \ ( (dictEq }, <, <= } -> dictEq 

(<) = \ ( ( dictEq }, <, <= } -> < 

(<=) = \ ( ( dictEq ), <, <= ) -> <= 

Each overloaded function has extra parameters corresponding to the required 
dictionaries. Here is the translation of search from Section 2.2: 

search = \ dOrd x ys -> not (null ys) && 

( (==) (getEqFromOrd dOrd) x (head ys) I I 

( (<) dOrd x (head ys) && search dOrd x (tail ys))) 

Each call of an overloaded function supplies the appropriate parameters. Thus the 
term (search 1 [2,3]) translates to (search dictOrdlnt 1 [2,3]). 

If an instance declaration has a context, then its translation has parameters 
corresponding to the required dictionaries. Here is the translation for the instance 
(Eq a) => Eq [a] from Section 2.1: 

dictEqList = \ dEq -> (\ xs ys -> 

( null xs && null ys ) I I 
( not (null xs) && not (null ys) && 
(==) dEq (head xs) (head ys) && 
(==) (dictEqList dEq) (tail xs) (tail ys))) 

When given a dictionary for Eq a this yields a dictionary for Eq [a] . To get a 
dictionary for equality on list of integers, one writes dictEqList dictEqlnt. 

The actual target language used differs from the above in that it contains extra 
constructs for explicit polymorphism. See Section 3.2 for examples. 

3. NOTATION 

This section introduces the syntax of types, the source language, the target lan- 
guage, and the various environments that appear in the type inference rules. 

3.1 Type Syntax 

Figure 1 gives the syntax of types. Types come in three flavors: simple, overloaded, 
and polymorphic. Recall from the previous section the type signature for search, 
(Ord a) => a -> [a] -> Bool, which we now write in the form Va.(Ord a) => 
a — > List a — ► Bool. This is a polymorphic type of the form a = Ma. 9 => r built 
from a context 9 = (Ord a) and a simple type r = a — > List a — > Bool. There 
are also record types, 7, which map class operation names to their types. These 
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Fig. 1. Syntax of types. 



program 


— » classdecls ; instdecls ; exp 


Programs 


classdecls 


— > classdecli; . . . ; classdecln 


Class declaration (n > 0) 


instdecls 


— » instdech instdecl n 


Instance declaration (n > 0) 


classdecl 


— » class 0 => k o 
where 7 


Class declaration 


instdecl 


— » instance 0 => « (x ai . . . a^) 
where binds 


Instance declaration (fc > 0) 


binds 


— > (uari = espi , . . . , nar„ = eip„) 


(n > 0) 


exp 


— > mr 


Variable 




A t)ar . exp 


Function abstraction 




exp exp' 


Function application 




let liar = exp' in exp 


Local definition 



Fig. 2. Syntax of source programs. 



appear in the source syntax for classes. Here Ord is a class name; List is a type 
constructor of arity 1; and Bool is a type constructor of arity 0. 

There is one subtlety. In an overloaded type p or a saturated context tfi, entries 
may have the form k t, whereas in a polymorphic type a or a context 9 entries are 
restricted to the form k a (as with the palindrome example from Section 2.1. The 
extra generality of overloaded types is required during the inference process. 

3.2 Source and Target Syntax 

Figure 2 gives the syntax of the source language. A program consists of a sequence of 
class and instance declarations, followed by an expression. The Haskell language 
also includes features such as type declarations and pattern matching, which have 
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program 
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Function abstraction 
Function application 
Local definition 
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Type abstraction (n > 1) 
Type application (n > 1) 
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— » var : r 


(n > 0) 



Fig. 3. Syntax of target programs. 
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Notation 


Type 
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Type constructor environment 
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Type class environment 


CE 


{k : class 0 => K a where 7} 
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Local instance environment 
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VE 


{var : a} 


Environment 
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(AE, TE, CE, IE, LIE, VE) 
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({},TE,CE,IE,{},VE) 


Declaration environment 


DE 


(CE,IE,VE) 



Fig. 4. Environments. 



been omitted here for simplicity. The examples from the previous section fit the 
source syntax precisely. 

Figure 3 gives the syntax of the target language. We write the nonterminals of 
translated programs in boldface: the translated form of var is var and of exp is 
exp. To indicate that some target language variables and expressions represent 
dictionaries, we also use dvar and dexp. 

The target language uses explicit polymorphism. It gives the type of bound 
variables in function abstractions, and it includes constructs to build and select 
from dictionaries and to perform type abstraction and application. A program 
consists of a set of bindings, which may be mutually recursive, followed by an 
expression. Type inference rules for this language appear in Section 5. 

Notice that no class types appear in the translation. Given an environment E as 
defined below, a context 9 or record type 7 can be converted into a monotype by 
tran E 9 or tran E 7. The tran function is defined in Section 4.7. 

3.3 Environments 

The inference rules use a number of different environments, which are summarized 
in Figure 4. 
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Fig. 5. Initial environments. 



The environment contains sufficient information to verify that all type variables, 
type constructors, class names, and individual variables appearing in a type or 
expression are valid. Environments come in two flavors: map environments and 
compound environments. 

A map environment associates names with information. We write ENV name = 
info to indicate that environment ENV maps name name to information info. If 
the information is not of interest, we just write ENV name to indicate that name is 
in the domain of ENV. The type of a map environment is written in the symbolic 
form {name : info}. 

We have the following map environments. 

— The type variable environment AE contains each type variable name a that may 
appear in a valid type. This is the one example of a degenerate map, where there 
is no information associated with a name. We write AE a to indicate that a is 
in AE. 

— The type constructor environment TE maps each type constructor \ to its arity 
k. 

— The type class environment CE maps a class name k to a class declaration, which 
contains all of the required type information. 

— The instance environment IE maps a dictionary variable dvar to its correspond- 
ing type. The type indicates that dvar is a polymorphic function that expects 
one dictionary for each entry in 0 and returns a dictionary for k t. This en- 
vironment is used to record information about globally visible dictionaries and 
dictionary selectors. 
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— The local instance environment LIE is similar, except that the associated type 
is monomorphic. Here the type indicates that dvar is a dictionary for k t. This 
environment is used to record information about specific dictionaries. 

— The variable environment VE maps a variable var to its associated polymorphic 
type a. 

Environments corresponding to the examples in Section 2 are shown in Figure 5. 

A compound environment consists of a tuple of other environments. We have the 
following compound environments. 

— Most judgments use an environment E consisting of a type variable, a type con- 
structor, a type class, an instance, a local instance, and a variable environment. 

— Top-level rules such as those for class and instance declarations use an initial 
version PE of the environment E. This contains an empty AE and LIE. 

— The judgments for class declarations produce a declaration environment DE 
consisting of a type class, an instance, and a variable environment. 

Again, these are summarized in Figure 4. We write VE of E to extract the 
type environment VE from the compound environment E, and similarly for other 
components of compound environments. 

The operations © and 0 combine environments. The former checks that the 
domains of its arguments are distinct, while the latter "shadows" its left argument 
with its right: 

(ENVi © ENV 2 ) var = 
( ENVi var if var G dom(ENVi) and var (jL dom(ENV 2 ) 
\ ENV 2 var if var G dom(ENV 2 ) and var <£ dom(ENVi), 

{ENVi © ENV 2 ) var = 
( ENVi var if var G dom(ENVi) and var £ dom(ENV 2 ) 
\ ENV 2 var if var G dom(ENV 2 ). 

For brevity, we write E\ © E 2 instead of a tuple of the sums of the components of 
Ei and E 2 ; and we write E © VE to combine VE into the appropriate component 
of E, and similarly for other environments. Sometimes we specify the components 
of an environment explicitly and write ®ENV~ 

There are three implicit side conditions associated with environments: 

(1) Variables may not be declared twice in the same scope. If E\ 0 E 2 appears in 
a rule, then the side condition dom(Ei) n dom(E 2 ) = 0 is implied. 

(2) Every variable must appear in the environment. If E var appears in a rule, 
then the side condition var G dom(E) is implied. 

(3) At most one instance can be declared for a given class and given type construc- 
tor. If I Ei © IE 2 appears in a rule, then the side condition 

V ki (xi ai . . . a m ) G I Ei. V n 2 { X2 Pi . . . [3 n ) G IE 2 . Ki ± k 2 V \i + X2 

is implied. 
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type 

E h r 



over-type 

E h 6 => r 



poly-type 






£ h Vai,. 


. , an- 


0 => r 



TYPE-VAR ( AE °f g ) a 

type 

E h a 



TYPE-CON 



(TE of E) X = k 

type 

E h Ti (1 < i < fc) 

type 



(CE of E) Ki (1 < i < m) 
(AE of E) on (1 < i < m) 

type 
E h r 

TYPE-PRED 



TYPE-GEN 



over-type 

i? h (ki ai,...,/c m a m > =>- r 



over-type 

Ee AE {ai,...,a fe } h 0=! 

poly-type 

£ h Vai ■ • • a k . 6 T 



Fig. 6. Type formation rules. 



In some rules, types in the source syntax constrain the environments generated 
from them. This is stated explicitly by the determines relation, defined as: 



r determines AE ftv(r) = AE 
9 determines LIE ^=^> 8 = ran(LIE). 



4. RULES 



This section gives the inference rules for the various constructs in the source lan- 
guage. We consider in turn types, expressions, dictionaries, class declarations, 
instance declarations, and full programs. 
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4.1 Types 

The rules for types are shown in Figure 6. The three judgment forms defined are 
summarized in the upper left corner. A judgment of the form 

type 
E h T 

holds if in environment E the simple type r is valid. In particular, all type variables 
in t must appear in AE of E (as checked by rule TYPE-VAR), and all type 
constructors in r must appear in TE of E with the appropriate arity (as checked 
by rule TYPE-CON). The other judgments act similarly for overloaded types and 
polymorphic types. 

Here are some steps involved in validating the type Va. (Ord a) => a — > a — > 
Bool. Let AE = {a}, and let E 0 be as in Figure 5. Then the following are valid 
judgments: 

type 

(1) E 0 ®AE h a -» a -» Bool, 

over-type 

(2) E 0 © AE h (Ord a) => a -> a -> Bool, 

poly-type 

(3) E 0 h Va. (Ord a) => a -» a -» Bool. 

Judgment (1) yields (2) via TYPE-PRED, and judgment (2) yields (3) via TYPE- 
GEN. 

The type inference rules are designed to ensure that all types that arise are valid, 
given that all types in the initial environment arc valid. In particular, if all types 
appearing in the CE, IE, LIE, and VE components of E are valid with respect 
to E, this property will be preserved throughout the application of the rules. 

4.2 Expressions 

The rules for expressions are shown in Figures 7-8. A judgment of the form 

exp 

E h exp : t ~> exp 

holds if in environment E the expression exp has simple type r and yields the trans- 
lation exp. The other two judgments act similarly for overloaded and polymorphic 
types. 

The rules are very similar to those for the Hindley-Milner system. The rule TAUT 
handles variables; the rule LET handles let bindings; the rules ABS and COMB 
introduce and eliminate function types; and the rules GEN and SPEC introduce and 
eliminate type quantifiers. The new rules PRED and REL introduce and eliminate 
contexts. Just as the rule GEN shrinks the type variable environment AE, the rule 
PRED shrinks the local instance environment LIE. Unlike the original Hindley- 
Milner system and most of its derivatives, we have chosen to restrict type variable 
generalization and specialization: our rules do not allow spurious type variables 
to be introduced by GEN to be removed by SPEC. This is partly a matter of 
taste, in that it more closely reflects the type algorithm, but it also reduces the 
size of the translation and eliminates the possibility that alternative but equivalent 
translations could be produced by these rules. 

Here are some steps involved in typing the phrase \ x y -> x < y. Let E 0 be as 
in Figure 5, and let AE = {a}, LIE = {dOrd : Ord a}, and VE = {x : a,y : a}. 

ACM Transactions on Programming Languages, Vol. 18, No. 2, March 1996. 



122 • Cordelia V. Hall et al. 



E h exp : r ~> exp 



E 


over-exp 

h 


exp 


: p ~> exp 














E 


poly-exp 

h 


exp 


: a exp 






TAUT 




(VE of E) var = a 




E 


poly-exp 

h var : a 





SPEC 



poly-exp 

E h var : Vc*i . . . =3> r var 

type 

E h t< (1 < i < fc) 

over-exp 

_B h mr : (9 =>■ r)[n/ai, . . . , T k /a k ] ~> var n . . . r fc 



REL 



over-exp 

B h far :</>=> t ~> exp 

diets 

_B h 0 ~> dexps 

exp 

_B h var : r ~+ exp dexps 



ABS 



^ ffivB {var : t'} h exp : r ~> exp 
i? h A^ar. exp : r' — + r ~> Avar: r'. exp 



COMB 



-B h exp : r' — > r ~> exp 

exp 

E h exp' : t' ~> exp' 

2xp 

E h (exp exp') : r ~> (exp exp') 



Fig. 7. Rules for expressions, part 1. 



Then the following arc valid judgments: 

exp 

(1) E Q ® AE ® LIE ®VE h x < y : Bool ^ (<) a dOrd x y 

(2) E 0 ®AE® LIE h \ x y -> x < y : a ^ a ^ Bool 

Ax : a. Ay : a. (<) a dOrd x y 

over-exp 

(3) E 0 ® AE h \xy->x<y: (Ord a) a — > a -> Bool 

^> 

A dOrd : (tran £ 0 (Ord a)) . 

A x : a . Ay : a . (<) a dOrd x y 
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PRED 


diets 

E © LIE h 9 «-* dpat 6 determines ZJ£ 

exp 

E © L/E h esp : r exp 




over-exp 

E h exp : 6 => r ~> A dpat : trcm £ (0) . exp 


GEN 


over-exp 

E ®AE { a l> • ■ • i a k} l~ ex V '■ 0 => T ~> ex P 


E 


poly-exp 

h exp : Vai . . . . 6 r ~> Aai . . . . exp 


LET 


poly-exp 

E h exp' : cr ~> exp' 

E ffivB {var : cr} h exp : r — > exp 


E 


exp 

h let var = exp' in exp : r ~> let var = exp' in exp 



Fig. 8. Rules for expressions, part 2. 



(4) E 0 h \ x y -> x < y : V<x (Ord a) => a — > a — > Bool 

^> 

A a . A dOrd : (iran i? 0 (Ord a)) . 

A x : a . Ay : a . (<) a dOrd x y 
Judgment (1) yields (2) via ABS; judgment (2) yields (3) via PRED; and judgment 
(3) yields (4) via GEN. The tran function is defined in Section 4.7. 

As is usual with such rules, one is required to use prescience to guess the right 
initial environments. For the SPEC and GEN rules, the method of transforming 
prescience into an algorithm is well known: one generates equations relating types 
during the inference process and then solves these equations via unification. For 
the PRED and REL rules, a similar method of generating equations can be derived. 

4.3 Dictionaries 

The inference rules for dictionaries are shown in Figure 9. A judgment of the form 

diet 

E h k t dexp 

holds if in environment E there is an instance of class k at type r given by the dictio- 
nary dexp. The other two judgments act similarly for overloaded and polymorphic 
instances. 

The two DICT-TAUT rules find instances in the IE and LIE component of 
the environment. The DICT-SPEC rule instantiates a polymorphic dictionary, by 
applying it to a type. Similarly, the DICT-REL rule instantiates an overloaded 
dictionary, by applying it to other dictionaries, themselves derived by recursive 
application of the dictionary judgment. 

The rule that translates an entire context into a tuple of the corresponding dic- 
tionaries has the judgment form 
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diet 

E h k r 'x* dexp 



over-diet 

i£ h 0 =4> k. r dexp 



poly-diet 






£ h Vai . 




•+ dexp 



diets 

E h if> ~> dexps 



DICT- TAUT-LIE °/ £) dvar = K a 

diet 

_B h re a dvar 



DICT- TAUT-IE {IE. °f E ^ dvar = Vctl e =^ K (x "l ■■ ■ "») 

poly-dict 

-E h Vai . . . a n . 0 k (x cki • ■ ■ Q-n) ~* dvar 



DICT-SPEC 



poly-dict 

i? h Vai . . . ctn .0 = ^ k t 'v* dexp 

over-diet 

£ h (6» => re r) [ri /qi ,t„ /a„] ~» dexp n . . . r n 



DICT-REL 



over-diet 

E h ^sr ^ dexp 

diets 

E \- (f> dexps 

diet 

_B h re t ~v dexp dexps 



DICTS 



diet 

B h Ki Ti ~> dexp { 



(1 < i < n) 



E h (ki Ti,...,/t n T„) ~> (dexp 1 ,...,dexp„) 



Fig. 9. Rules for dictionaries. 



E h 0 ~> dexps 

Here is how to derive a dictionary for the instance of class Eq at type Int. Let 
E 0 be as in Figure 5. Then the following judgments hold: 

poly-dict 

(1) E 0 h Va. (Eq a) Eq (List a) ^> dictEqList 

over-diet 

(2) E 0 h (Eq Int) => Eq (List Int) ^ dictEqList Int 

diet 

(3) E 0 I" Eq Int ^ dictEqlnt 

diet 

(4) E 0 h Eq (List Int) ^ dictEqList Int dictEqlnt 
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sigs 

E h sigs ~» sigs 



SIGS 



type 

E h Ti (1 < i < m) 



E h (uari : n, . . . , mr m : r m ) ~> (uori, . . . , var m ) 



Fig. 10. Rule for class signatures. 



classdeel 

E h classdeel : DE ~> bindset 



CLASS 



type 

PE © AE ha ct determines AE 

diets 

PE © © LIE h 9 ~> dpat 6» determines IPE 

sigs 

PE0AE h 7 ~* mpat 

pat = (dpat, mpat) : (PE (6),PE (7)) 



classdeel 

PE h class 0 => k q where 7 



({k : class 0 => k a where 7}, 

{dvar : A a. (k a) => k' t' | dvar : «' r' £ i/E}, 
{var : A a. (k a) => r | var : r £ 7}) 

{dvar = V a. X pat . dvar | dvar £ dom(LIE)} U 
{var = V a. Apat . var | var £ dom^)} 



Fig. 11. Rule for class declarations. 



Judgment (1) holds via DICT-TAUT-IE; judgment (2) follows from (1) via DICT- 
SPEC; judgment (3) holds via DICT-TAUT-IE; and judgment (4) follows from (2) 
and (3) via DICT-REL. 

Note that the dictionary rules correspond closely to the TAUT, SPEC, and REL 
rules for expressions. 

4.4 Class Declarations 

The rule for class declarations is given in Figure 11. Although the rule looks 
formidable, its workings are straightforward. 
A judgment of the form 

classdeel 

PE h classdeel : DE ^ bindset 

holds if in environment PE the class declaration classdeel is valid, generating new 
environment DE and yielding translation bindset. In the compound environment 
DE = (CE, IE, VE), the class environment CE has one entry that describes the 
class itself; the instance environment IE has one entry for each superclass of the 
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instdecl 

E h instdecl : IE ~> bindset 



INST 



(CE of PE) k 
PE 



type 
AE h 



class 6' K a where 7' 

t determines AE 
6 determines LIE 



dpat 



diets 

PE® AE® LIE h 0 

diets 

PE® AE ® LIE h e'[r/a] ~> dexp 

binds 

PE ® AE ® LIE h binds : 7'[r/a] ~-> exp 



instdecl 

PE h instance 0 => re r where feirads : {dvar = V dom(AE). 8 => re r} 
dvar = A doin(AE) . A dpat : tram ?E (9) . (dexp, exp) 



Fig. 12. Rule for instance declarations. 



binds 

£ h binds : 7 ~> exp 



BINDS 



E h expi : exp i ~> t. 



(1 < i < m) 



£ h («ari = expi , . . . , «ar m = exp m ) ■ (vari : Ti , . . . , -uar m : r m ) 
(ex Pl ,...,expJ 



Fig. 13. Rule for instance bindings. 



class (given the class dictionary, it selects the appropriate superclass dictionary); 
and the value environment VE has one entry for each operator of the class (given 
the class dictionary it selects the appropriate method). 

For example, the class declaration for Ord given in Section 2.2 yields the Ord 
component of CE 0 , the getEqFromOrd component of IE 0 , and the (<) and (<=) 
components of VE 0 , as found in Figure 5. The binding set generated by the rule 
is as shown in Section 2.3. 



4.5 Instance Declarations 

The rule for instance declarations is given in Figure 12. Again the rule looks 
formidable, and again its workings are straightforward. 
A judgment of the form 

instdecl 

PE h instdecl : IE ^> bindset 

holds if in environment PE the instance declaration instdecl is valid, generating new 
environment IE and yielding translation bindset. The instance environment IE 
contains a single entry corresponding to the instance declaration, and the bindset 
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classdecls 

PE h classdecls : DE ~> bindset 



PE © DPi © ... © DEi-i h classdecli : DE t 
CDECLS bindset, (1 < i < n) 

classdecls 

Pi? h classdecli ; • • • ; classdecl n : DE\ © ... © PP„ 
bindseti; ... ; bindset n 



instdecls 

PE h instdecls : IE ~> bindset 



IDECLS 



instdecl 

PS h instdecli : 7_E^ ^ bindseti (1 < i < n) 

instdecls 

Pi? h instdech ; . . . ; instdecl n : (IE of PE) © i£a © ... © iE„ 

^> 

bindseti; ■•■ ; bindset n 



program 






PE h program 


T 


~+ exp 



classdecls 

(1) PS h classdecls : DS ^ bindset q 

instdecls 

(2) PE © DE © iP h instdecls : IE ~v bindset/ 

exp 

(3) PE® DE® IE h exp : t ~> exp 

program 

PP h classdecls ; instdecls ; exp : r 

letrec bindseto; bindset/ in exp 



Fig. 14. Rules for declaration sequences and programs. 



contains a single binding. If the header of the instance declaration is 0 => k t, then 
the corresponding instance is a function that expects one dictionary for each entry 
in 9, and returns a dictionary for the instance. 

The first line looks up the superclasses and record type of the instance class. 
Line (2) sets AE to contain the type variables in t. Line (3) sets LIE to contain 
the types in 9, the instance context, and builds the pattern for the dictionary 
parameters. Line (4) checks that the superclasses are satisfied by the LIE and 
builds the dictionaries for those superclasses. Finally, line (5) checks that the 
method definitions have precisely the types of the class operations instantiated by 
the instance type, and builds the method translations. 

For example, the instance declarations for Eq Int, (Eq a) => Eq [a] , and Ord 
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Int yield the dictEqlnt, dictEqList, and dictOrdlnt components of IE 0 as found 
in Figure 5, and the bindings generated by the rule are as shown in Section 2.3. 

4.6 Programs 

Figure 14 gives the rules for declaration sequences and programs. 

The order of the class declarations is significant, because at the point of a class 
declaration all its superclasses must already be declared. (This guarantees that the 
superclass hierarchy forms a directed acyclic graph.) Further, all class declarations 
must come before all instance declarations. 

The order of the instance declarations is, however, irrelevant, because all instance 
declarations may be mutually recursive. Mutual recursion of polymorphic functions 
docs not cause the problems you might expect, because the instance declaration 
explicitly provides the needed type information. 

These differences are reflected in the different forms of the CDECLS and IDECLS 
rules. That instance declarations are mutually recursive is indicated by line (2) of 
the PROG rule, where the same environment IE appears on the left and right of 
the instdecls rule. 

In Haskell the source text need not be so ordered. A preprocessing phase performs 
a dependency analysis and places the declarations in a suitable order. 

4.7 Converting Contexts/Records to Monotypes 

Given an environment E, context and record types can be converted into monotypes 
using the function tran, defined below. 

tran E ((f)) = (tran E (n\ Ti), . . . ,tran E (n n t„)) 
where <j) — (k,\ t\, . . . , K n r„) 

tran E (n r) = (tran E (9 [r/a]), tran E (7 [r/a])) 

where (CE of E) k = (class 9 =4> n a where 7) 

tran £ (7) = (n, . . . , r„) where 7 = (v\ : n, . . . , v n : r„) 

This allows us to remove class types from the translation entirely. As an example, 
here is the translation of search from Section 2.3, amended to make all polymor- 
phism explicit: 

search = Aa. A dOrd : (tran Eo (Ord a)) . Ax : a. Ays: [a]. 

not (null a ys) && ( (==) a (getOrdFromEq a dOrd) x (head a ys) I I 

( (<) a dOrd x (head a ys) && search a dOrd x (tail a ys))) 

The translation of the dictionary, tran Eq (Ord cv) is: 

tran Eo (Ord a) = 

( ( ( ( (), (a -» a -> Bool) ), (a -> a -> Bool, a -> a -> Bool) ) ) 

5. SOUNDNESS, COMPLETENESS, AND PRINCIPAL TYPING RESULTS 

We do not attempt to prove soundness and completeness results here, but it is a 
useful exercise to state the form of these results and to sketch their proofs. Equiva- 
lent results have been proved by Blott [1991] and Jones [1992b] for their respective 
type systems, which arc broadly similar to that presented here. It is thus expected 
that their proofs will carry over in large part to this system. 
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5.1 The Type System 

Some results can be obtained directly from the type system. The most important 
of these is that the type system has principal types. This relics on definitions of 
generality for polymorphic types and on the notion of a canonical form for contexts. 

5.1.1 Canonical Contexts. There is a canonical form for contexts and saturated 
contexts, which is unique up to the ordering of n r pairs. 

Definition 1. A canonical context, (k\ n, . . . , K n t„) is one where 

(1) all k t pairs have the form n a; 

(2) no class k appearing in a k a constraint is a superclass of a class k' appearing 
in another constraint n' a on the same type variable a; and 

(3) there are no duplicate k a pairs. 

Definition 2. A superclass of some class n is 

(1) any class appearing in the context of the class definition for k; or 

(2) a superclass of any such class. 

The canonical form of a context is produced by the canon function. This trans- 
forms a saturated context (p into a minimal context 6 by: 

— generating the transitive closure of n t pairs under the defined instance hierarchy; 

removing all trivially satisificd constraints k t where r is not a type variable; 
— removing all superclasses for each k a pair; and 
— finally eliminating all remaining duplicate constraints. 

Note that the type rules (DICT-TAUT-IE in conjunction with REL and SPEC) 
ensure that for all k t constraints, r is an instance of k, so there is no possibility 
of failure here. 

canon E (f> — mincontext E <fi' where (dpat,(p') = diets simp i E {} <j> 

The canon function requires two subsidiary functions: dicts S i mp i and mincontext. 
The dictSsimpi function is used to generate the transitive closure of </>. Only the 
global instance environment component of E is actually used. 

dicts simp i E LIE («i n, . . . , «„ r„) = 

let (dpat^ (/tii Tn, ■ • • , Kij Tij)) = dict cxt E LIE k\ t\ in 

let (dpat„, (k„i t„i, . . . , K nk T nk )) = dict cxt E LIE 

T n m 

( [[ (dpati, . . . , dpatj ]], (/t u m, . . . , n lo nj,..., K nl T nl , . . . , n nk r nk )) 

dict cx t E LIE k a = 

let dvar = lookupLiE « oe in 
( [[dvar ]],(««)) 
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dict cxt E LIE k (xn ... T n ) = 
let (dvar, V a\ . . . a n . 6 => r) 
let (dpats, (j)) 
( [[ ( dvar dpats ) }},(j>) 



lookup j e (IE of E) k x in 
dictssimpi E (0[Ti/ai, . . . ,r„/a„]) in 



The mincontext function "minimizes" a saturated context by eliminating dupli- 
cate k a pairs and all n t pairs. 

mincontext E (f> — (k\ a±, . . . , k„ a n ) such that a; <G (j) an d 
subclasses E Ki n <t> = 0 for all i with 1 < i < n and 
Ki cti ^ Kj ctj for all i, j with 1 <i<j<n,i^j 

subclasses E k = 

{ k' such that (k 1 :(..., k a, . . .) => k' a where 7) e (CE of E) } 

5.1.2 Generality of Types. In order to present the principal type result, it is 
necessary to introduce an ordering relation on types, >, such that a > a' means a 
is no less general than a'. 

We first introduce substitutions, idempotent environments mapping type vari- 
ables to types, with the usual conventions. Thus if 5* is { a : t }, then, for 
example: 

S (x ol Int a) — x T Int r 
and S (S a) = S a = r 

A saturated context <f> is at least as general as another saturated context <f> if it is 
entirely contained within the canonical form of that context. We use the notation 
4> C <j}' to mean that </> contains no duplicate entries, and every entry in <f> also 
appears in (f)' . Thus, a smaller context is more general than a larger one, and the 
empty context is most general of all. 

(p > (j> if 0 C canon E (<fi') 

(Note that generality for saturated contexts depends on the prevailing instance 
environment, IE.) 

Now it is possible to define a generality relation > over polymorphic types, 
V a x . . . a n . (f> => t > V ft . . . f3 n . cj>' r' 
if there exists a substitution 5* such that 5* r = t' and (S (f>) > (j)' . 

5.1.3 Principal Types. A type r is the principal type of p under PE if, and only 

if, 



program 



(1) PE h p : t ^ exp; and 

program 

(2) if, for some r', PE h p : t' ~> exp, then t > r' . 



program 

Definition 3. A typing Pi? h p : r ~> exp is a principal typing for 

program 

program p if whenever PP h p : t' ^ exp, we have t > t'. 

poly-exp 

Definition 4. A typing P h exp : c exp is a principal typing for 

poly-exp 

expression eirp if whenever E h exp : a' ^ exp, we have a > cr'. 
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E h exp 



A-bind 

E h exp : VE 



A-bind 

E © VE h bindset 



VE 



A-PROG 



E © VE h exp : r 



B h letrec bindset in exp : r 



A-BINDS 



A 

_B h expi : Tj (!<*<«•) 

A-bind 

E h vari = exp x ; . . . ; var„ = exp n : {vari : n , . . . , var„ : t„} 



Fig. 15. Rules for type calculus A: Programs and bindings. 

progra' 

Statement (Principal Types). If there exists a typing for program p, PE V- 

program 

p : t exp then there exists a principal typing for program p, PE h p : 

t' ~> exp . 

Lemma (Principal Types for Expressions). If there exists a typing for ex- 

poly- exp 

pression exp, E h exp : a ~> exp i/ien i/iere exists a principal typing for 

poly-exp 

expression exp, E h exp : it' ~» exp. 

Proof Sketch. The lemma can be proved by structural induction on programs 
and expressions. □ 

5.2 The Translation 

As noted above, since the translation defines the semantics of the type system a 
simple soundness result is not meaningful. It is, however, possible to prove the 
soundness of the translation with respect to the types derived by the type system. 

To prove these results, we need to refer to the type calculus for the second-order 
polymorphic lambda calculus, A, on the target language defined in Figure 3. A 
judgment of the form 

PE h exp : <5 

holds if in environment PE the type 5 is valid. Note that, unlike Reynolds' second- 
order polymorphic lambda calculus, but in common with the Hindlcy-Milncr type 
system, type system A only permits type variables to be quantified at the outer- 
most level of a type. The type structure for second-order types differs from that 
used for first-order polymorphic types in that: 

(1) there are no overloaded second-order types; 

(2) simple types include record types, which describe the types of dictionaries. 
The new syntax for second-order types is shown in Figure 18. 
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E h exp 



A-TAUT ( VE °f E ^ var = 5 

A 

E h var : <5 



A-pat 

E h pat : V.E 
A-ABS Effiv£yE ^xp : r 

A 

£ h A pat . exp : r 



A 

E h exp ; t' — ► t 

A-COMB E L eXP ' : T ' 

A 

£ h (exp exp') : r 



A 

£ h exp' : <5 

— > A 

E © {var : 5} h exp : r 

A 

E h let var = exp' in exp : r 



A-LET 



A-RECORD 



_B h expi : r< (1 < i < n) 

A 

E h (exp 1 ,...,exp n ) : (ti,...,t„) 



A-TYPE-ABS E ©AB{ai,---,Qn} ^ exp : t 

A 

E h Aoi...a» . exp : V Qi . . . a n . r 



A-TYPE-COMB 



A 

E h exp : V ai . . . a» . T 

— A 

_B h exp n . . .T n : r[n/ai, ■ ■ • , r n /a n ] 



Fig. 16. Rules for type calculus A: Expressions. 

Typing rules for expressions in our target language are given in Figures 15-17. 
Note that there are no equivalents to SPEC or GEN, which in our previous rules spe- 
cialized universally quantified types or introduced new type variables. Instead, all 
type variables are explicitly quantified by expressions of the form A a.\ . . . a n . exp 
and substituted by expressions of the form exp t\ . . . r„. Since the second-order 
types cannot be overloaded, there are also no equivalents to REL or PRED. 
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A-pat 

E h pat : VE 



A-PAT- VAR _ 

E h (var : r) : {var : r} 

A-pat 

A-PAT-REC E h pat ' : VEi (1 < i < n) 

A-pat 

E h (pat^-.^patj : l/Eiffi...©VE„ 



Fig. 17. Rules for type calculus A: Patterns. 



Second-Order Polymorphic Type 


8 Vai . 


. . a n • T 


(n > 0) 


Simple type 


r — » a 








1 x n 


■■T„ 


(n > 0, n = arity(x)) 




1 r'-» 


T 






1 <n,. 


■ ■ ,Tn> 


(n > 0) 



Fig. 18. Syntax of second-order types. 



5.2.1 Type Soundness. Given a typing in our type calculus, then the type of 
the translation can be directly related to the type given by that typing. To state 
this formally we first need to introduce a property relating first-order polymorphic 
types to second-order types. 

Definition 5. A polymorphic type a has the second-order translation S, written 
a* = S, as follows: 

( Vai • • • a n . p )* = Vai . . . a„ . t 1 , if p* = t' 

( o =*• r y 

( («i n, . . . , K n r n ) => t )* = (dicttype K\ n, . . . , dicttype K n r„) — » r 

This uses a function to convert class names into dictionary types, dicttype. 

dicttype k t = (t±, . . . , r„) [r/a] 

where [[ class 9 => k a where (vi : n, . . . , v n : r„) ]] = CE k 

Statement (Type Soundness for Programs). Given a typing 

program 

PE h program : r ^> exp, 

A 

then there exists a typing PE h exp : t'. Furthermore t = t' . 

This result relies on the following lemma for expressions and similar lemmas for 
declaration bindings. 
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Lemma (Type Soundness for Expressions). Given a typing E h exp : 

A 

a ~> exp then there exists a typing E h exp : (5. Furthermore a* = S. 

PROOF Sketch. The lemma can be proved by structural induction on the rules 
for programs and expressions and by reference to the typings for the translated 
terms. □ 



6. IMPLEMENTING A TYPE INFERENCE ALGORITHM 

This section sketches the implementation of a type inference algorithm based on the 
rules above. For simplicity, we will follow the conventional practice of defining an 
explicit substitution-based algorithm (as described by Cardelli [1987], for example), 
though we note that, in practice, graph-based algorithms are often more efficient. 
Hammond [1991] describes a graph-based algorithm using monads [Wadler 1992] 
that is similar to the one we use in the Glasgow Haskell compiler. 

When deriving an inference algorithm from type rules such as these, it is common 
practice to define a set of functions that each implement a single rule or related 
set of rules. The arguments to the function are those items that appear to the 
left of the turnstile in the rule, while the results of the function are those items 
that appear to the right of the turnstile. So, given a rule which gives the types of 
expressions that yield polymorphic types (of type a) , whose form is 

poly-exp 

E h exp : a ~» exp 

then the arguments to the inference function are a type environment E and an 
expression exp, and the outputs of the function are a polytype a and a translated 
expression exp. 

Since our rules have been defined relationally, however, there are some places 
where this simple scheme is insufficient. We will now consider each of these cases 
below. 

The first issue that must be addressed is how to resolve the circularity in the 
rules for instance declarations and programs. 

(!)■•■ 

(2) PE®DE®IE "h" " instdecls : IE ~> bindset/ 
PROG ^ '•• 

program 

PE h ... 

Here the same instance environment, IE, that is returned from the instdecls rule 
is also injected into the environment that is passed to it as an argument. The 
solution we adopt is to simply use a fixpoint in the function that implements the 
PROGRAM rule. This uses laziness in an essential way. 

Second, we need to decide how to relate dictionaries to types in the PRED rule. 

diets 

E © LIE h «m dpat 9 determines LIE 

exp 

E © LIE h exp : r ~> exp 

over-exp 

E h exp '. 0 =r* t ~> A dpat : tran E (8) . exp 



PRED 
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The translated dictionary pattern, dpat, depends on the local instance environment 
LIE that is an input to the diets rule. This therefore needs to be generated as a 
result of function that implements the exp rule. 

The final issue is how to implement the inference rules for dictionaries, diets: 



diets 



E h <j> ~» dexps 

These are somewhat problematic because they are used in three distinct ways 
throughout the rules. We therefore need to provide three different functions that 
each implement one of these three uses. 
The rules are used to produce 

(1) a dictionary pattern and a local instance environment from an environment 
and a context in INST and CLASS 

(INST) E © LIE V 9 ~> dpat 9 determines LIE 

diets 

(CLASS) PE © AE © LIE h 9 ~> dpat 9 determines LIE 

in which case, the diets function takes an environment E and a context 9 as 
its arguments and produces a translated dictionary pattern dpat and a local 
instance environment LIE as its results; 

(2) the corresponding dictionary expression from the augmented environment and 
a context in INST and REL 

diets 



(INST) PE® AE® LIE h 6'[r/a] ~» dexp 

diets 

(REL) E h (f> ~> dexps 



in which case, the diets function takes an environment E and a saturated 
context 4> as its arguments and produces a translated dictionary expression 
dexp as its result; 
(3) or a context and the corresponding dictionary pattern in PRED 



diets 



(PRED) E © LIE h 6 ~> dpat 9 determines LIE 

in which case the diets function takes an environment E and a local instance 
environment LIE as its arguments and produces a translated dictionary pattern 
dpat and a context 9 as its results. 

Notice in the third case, that despite the ordering in the determines relation, LIE 
is an argument to diets cxt , and 9 is a result. 

Only the instance environment components (both global and local) of the en- 
vironment are used in each case. These rules use the global and local instance 
environments in the opposite way from their normal use as environments: matches 
are made on the co-domain of the environment rather than its domain. 

6.1 Optimizations 

There are several optimizations that can be applied to improve the translation 
described above [Augustsson 1993; Hammond and Blott 1989; Jones 1992c]. For 
example, 
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— Specialized versions could be produced for each overloaded function, so that each 
use of that function can be compiled without introducing dictionaries. 

— Methods could be "inlined." 

— Dictionaries could be partially applied in order to reduce the number of times 
that dictionary functions are applied at run-time. 

— Parameterized dictionaries can be lifted from recursive overloaded definitions, so 
avoiding reconstructing them in each recursive call. 

— The well-known common sub- expression elimination optimisation, which involves 
replacing two or more identical sub-expressions in an expression by a single shared 
sub-expression, can be used to avoid constructing identical dictionaries several 
times. 

These optimizations have already been at least partially adopted by several of 
the more optimizing Haskell compilers, and there is evidence that significant per- 
formance improvements can result [Augustsson 1993]. 

7. CONCLUSIONS 

The main contribution of this article is that it presents a minimal, readable set 
of inference rules to handle type classes in Haskell, derived from the full static 
semantics of Haskell [Peyton Jones and Wadler 1991]. We have treated most of 
the essential characteristics of Haskell, including a direct treatment of the type 
class hierarchy (this is a minor theoretical point, but it is a practical advantage to 
be able to express errors in terms of the classes the programmer has used). We 
have also briefly described how the type rules can be implemented. For simplicity, 
we have omitted discussions of the monomorphism restriction, ambiguity (default 
resolution), and default methods. These are dealt with at length in the full static 
semantics and elsewhere, e.g., Blott [1991] and Nipkow and Prehofer [1993]. 

An important feature of this style of presentation is that it scales up well to 
a description of the entire Haskell language, as we have found in practice. It is 
also straightforward to extend the rules to more esoteric cases, such as classes 
constraining more than one overloaded type [Hammond 1993]. 
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